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Getting Rid of Marking 


Though we realize that this improvement is perhaps somewhat late 
to be implemented, we believe that there exist better solutions than 
marking and suggest a simple modification to the IMP-HOST interface 
which would avoid it. 


1. The harm. 


Marking was introduced to suit the sending Host because it permits 
the text of a message to start on a word boundary, however, it does not 
suit the receiving Host with a different word length. Moreover, it 
introduces in the message useless bits. Let us illustrate this by the 
example of our Sigma 7, a 32 bit machine. 


1.1 Inefficiency in Computation 


Suppose we receive a message from an 18 bit machine (figure 1.1) 
coded in 8 bit ASCII characters which will eventually become standard on 
the network. In order to translate this message into our EBCDIC 
internal code, for instance. 


message message 


figure 1.1 
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we first have to shift the whole message. We must detect the firsl 1 
following the leader, and from this determine that we must shift the 
message 4 bits to the left. This takes approximately 12 psec per double 
word, which makes 1,5 msec per full regular message. This is not huge, 
but still it is about one-third of the time it will take to translate 
the message in internal code. 


1.2 Inefficiency in transmission 


More important is the inefficiency resulting from adding 
unnecessary bits to the message, especially if it turns out that one 
character messages are used. Figure 1.2 shows the example of a 1 
character text sent by the sigma 7, which results in transmitting 112 
bits to carry 8 bits of information, thus leading to an efficiency 
factor of 0.07. Supression of marking would 


Sigma 7 | leader | 


Message | 0O000000000000000000000000000001 | 


16 bits of padding | 1000000000000000 | 
added by sending IMP = --~---~--~---~---------- 


figure 1.2 
increase this efficiency to 0.10. For a 32 bit text (length of some 
control commands), it would increase the efficiency form 0.28 to 0.4. 
For one packet messages, the efficiency would still be increased by 3%. 
2. A remedy. 
This is a suggested modification of the Host-Imp users interface 


which has been tentatively sketched on diagrams extracted form BBN 1822 
report. 


[Page 2] 


RFC 64 Getting Rid of Marking 


2.1 Host to Imp 


The modification consists of adding a counter to 32, enabled 
as the beginning of a message, and incremented at each bit passed to the 
IMP; when it reaches 32 it forces a "word complete" signal asking for a 
new word in the shift register and resetting the word length counter; 
thus the unused bits in the last word of the leader are not transmitted 
and the message starts with the next word (see figure 2.1) 


0 23 
| leader | 
| | XXXXXXXXXXXXXXXX | <- contents of 
| ----------------------------------------- sending Host memory 
(24 bits) 
Message 


| message | 


figure 2.1 
2.2 Imp to Host 


The modification consists of adding a counter to 32. When 32 bits 
have entered the shift register form the Imp at the beginning of a new 
message, the counter allows the register to be shifted up to the point 
to be full (which is detected by the word length counter) without 
entering any new bit from the Imp. 
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Thus, the next bit of the message which is the first bit of text will be 
entered as the first bit of the next word (see figure 2.2). 


Message in receiving IMP memory Contents of receiving Host memory (35 
bits) 


0 15 0 35 
leader | | leader | 0000 
| i 4 | 
| message | | message | 
| | | | 
| be 4 | 
figure 2.2 


Though the accumulated cost of useless marking bits sent over the 
network plus computation to reshape received texts makes this 
modification probably whorkwhile being considered, this decision is not 
of our competence and we merely wanted to suggest a better solution then 
marking. 

Pages 5 and 6 contain a wire Diagram of a 


"TMP to Host" 


"Host’s special Interface" 


[ This RFC was put into machine readable form for entry ] 
[ into the online RFC archives by Gottfried Janik 2/98 ] 
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